1. Technical Field
The present invention relates in general to data processing and in particular to improving efficiency of data transmission and distribution within a data processing system network. Still more particularly, the present invention relates to a system, method and computer program product for storing on a server and delivering to a client a path maximum transmission unit value.
2. Description of the Related Art
The profusion of applications exchanging data across networks now enables a range of technologies inconceivable only a few years ago. Applications exchanging data over a network range from email clients and servers to World Wide Web browsers communicating with servers to Voice-over-Internet-Protocol (VoIP) applications.
Computers transmit data over the Internet in units called packets. Packets are transmitted across the Internet between a sending data processing system and a target data processing system through one or more relay data processing systems along a path or connection between the sending data processing system and the target data processing system. Optimal packet size for processing varies by application, as does the maximum packet size that various data processing systems can accommodate.
A recurring and frustrating problem is encountered when a packet, which was sent by a sending data processing system, is too large to be transmitted by a relaying data processing system, which receives it along the chosen path between the sending data processing system and the target data processing system. Packets that are too large to be retransmitted by a system along the path are frequently rejected as they are received.
Two conventional methods exist for handling the problems associated with the rejection of oversized packets. A sending computer can conventionally either permit packet fragmentation, a less preferred method used mostly by legacy systems, or provide for Path Maximum Transmission Unit (PMTU) discovery by asking for Internet Control Message Protocol (ICMP) notification when fragmentation would otherwise be needed to prevent rejection of an oversized packet.
By default, modern servers disable fragmentation and try to use PMTU discovery. Every network link has a maximum packet size called the link's Maximum Transmission Unit (MTU). The full path from one computer to another may travel across many links with different MTUs. The minimum of the MTUs for all of the links in a path is the PMTU. Even if a packet starts out on a network segment with a large MTU, it may later arrive at a link with a smaller MTU, and the link with the smaller MTU may reject the packet as being too large for retransmission. While most servers provide path segments with large MTUs, many users connect via links with reduced MTUs.
Solutions to the problem of oversized packets have evolved considerably over time. The original approach was to send only small packets corresponding to the TCP/IP default MTU (576 bytes). To this day, a sending system needs permission from the receiving system to send larger packets, but that permission is given as a matter of routine.
For some packets, especially those sent by older equipment, an oversized packet can be sent by breaking it into fragments and sending the fragments as smaller packets. The fragments can be reassembled downstream to reconstruct the original large packet, but this packet fragmentation creates problems involving both efficiency and security. Newer servers try to optimize their transmissions by discovering the PMTU and sending packets of the maximum acceptable size when there is enough data to fill them, the procedure for which was standardized and published as Internet Engineering Task Force Request For Comments (RFC) 1191 in 1990. By 2002, 80% to 90% of computers on the Internet used path MTU discovery.
The basic procedure of PMTU discovery involves sending the largest available packet that can be sent by the local system and waiting for a notification that the packet was too large. The notification that a packet was too large will contain information on the largest sendable packet size and will arrive as ICMP packets known as “fragmentation needed” ICMPs (ICMP type 3, subtype 4). The notifications are requested by setting the “do not fragment” (DF) bit in packets that are sent out. Unfortunately, the simple solution described above creates significant inefficiency when multiple systems on a network send large packets and receive error messages.
The first inefficiency created by the solution described above relates to the increased time necessary to transmit the individual packet, which is rejected as being too large and subsequently retransmitted. The oversized packet is delayed by being rejected, divided and resent as multiple packets.
The second inefficiency relates to the increase in the number of packets transmitted. Simply put, transmitting the initial oversized packet, transmitting the error notification message, and transmitting a correctly-sized packet, clogs the network with three rackets, where only one would have been required if sized correctly. The increase in the number of packets creates latency and delay with respect to all traffic on the network.
Both of these inefficiencies become yet more problematic as they are duplicated for several machines on a subnet.
Some applications (e.g. electronic mail and file transfer protocol clients) are able to tolerate high levels of latency and delay in data receipt. These clients were not designed with the perception of ‘real time’ interaction with the network, and users will tolerate a substantial aggregate delay between the time at which information is sent and the time at which it is received. Users are, however, generally less tolerant of the loss of information between the sending and receiving points, which sometimes occurs as a result of the need to resend packets, which is discussed above.
Increasingly, applications such as Voice over Internet Protocol or streaming video require the lowest possible delivery latency for information. What is needed is a way to optimize a message to correspond to the PMTU value for a connection to a target without incurring the latency associated with conventional PMTU discovery techniques.